Skip to content

fix: ship a runnable executable in every release - #7

Merged
Mysttic merged 1 commit into
masterfrom
develop
Jul 31, 2026
Merged

fix: ship a runnable executable in every release#7
Mysttic merged 1 commit into
masterfrom
develop

Conversation

@Mysttic

@Mysttic Mysttic commented Jul 31, 2026

Copy link
Copy Markdown
Owner

What

Releases 1.0.1 and 1.0.2 shipped a DLL and a handful of JSON files, which is not something anyone can start. Every platform now gets a self-contained, single-file executable that runs on a machine with no .NET installed.

Dropping the apphost in 1.0.1 dodged the Defender Trojan:Script/Wacatac.B!ml false positive, but it traded away the whole point of a release. An unsigned binary may still be flagged — that is a signing problem, not a packaging one, and it applied equally to the build that could not be run.

Release assets after this change

Asset Run it with Size
TargetApiSimulator-1.0.3-win-x64.zip TargetApiSimulator.exe ~47 MB
TargetApiSimulator-1.0.3-linux-x64.zip ./TargetApiSimulator ~49 MB
TargetApiSimulator-1.0.3-osx-arm64.zip ./TargetApiSimulator ~46 MB
TargetApiSimulator-1.0.3-portable.zip dotnet TargetApiSimulator.dll ~30 KB, needs the .NET 10 runtime

The three platform builds carry the .NET runtime inside the executable, which is where the 50 MB goes.

Contract impact

  • Endpoint(s): none
  • Status code changed: no
  • Response body changed: no

Packaging and startup defaults only. Console timestamps and the Microsoft.AspNetCore log filter move into code, so a standalone executable logs identically with no appsettings.json beside it. Configuration still overrides both.

Packages no longer carry web.config, aspnetcorev2_inprocess.dll or the static web assets manifest — IIS leftovers that made the download look unfinished. The pipeline guard is inverted: it now fails when a platform build produces no launcher, instead of failing when one is present.

Checklist

  • This is a release PR into master, so it targets master by design
  • dotnet test passes locally — 131 tests
  • dotnet format --verify-no-changes is clean
  • README updated — the download table now lists one asset per platform
  • Validation contract table unchanged; no request or response behaviour was touched
  • VERSION.md bumped to 1.0.3 and CHANGELOG.md has a [1.0.3] section

How to verify

Merging publishes v1.0.3. Then, from the release assets:

sha256sum -c TargetApiSimulator-1.0.3-linux-x64.zip.sha256
unzip TargetApiSimulator-1.0.3-linux-x64.zip -d tas && cd tas
./TargetApiSimulator --urls http://localhost:5000
curl -i -X POST http://localhost:5000/api/target \
  -H 'Content-Type: application/json' -d '{"key":"value"}'

Expected: 200 with body true, and 400 with {"ErrorMessage": "This is not JSON"} for anything that is not JSON.

Docker Hub secrets are still unset, so the 1.0.3 image will go to GHCR only. That no longer fails the release.

Releases 1.0.1 and 1.0.2 contained a DLL and a few JSON files, which is not
something anyone can start. Dropping the apphost dodged the Defender
Wacatac.B!ml false positive but traded away the whole point of a release.

Each platform now gets a self-contained, single-file build that runs on a
machine with no .NET installed:

  TargetApiSimulator-<version>-win-x64.zip    -> TargetApiSimulator.exe
  TargetApiSimulator-<version>-linux-x64.zip  -> ./TargetApiSimulator
  TargetApiSimulator-<version>-osx-arm64.zip  -> ./TargetApiSimulator
  TargetApiSimulator-<version>-portable.zip   -> dotnet TargetApiSimulator.dll

Console timestamps and the Microsoft.AspNetCore log filter move into code as
defaults, so a standalone executable logs identically with no files beside it.
Configuration still overrides both.

Packages no longer carry web.config, aspnetcorev2_inprocess.dll or the static
web assets manifest - IIS leftovers that made the download look unfinished.

The pipeline guard is inverted: it now fails when a platform build produces no
launcher, instead of failing when one is present.

An unsigned binary may still be flagged. That is a signing problem, not a
packaging one, and it applies equally to the version that could not be run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Mysttic
Mysttic merged commit d58d99f into master Jul 31, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant